A basic concept in the 3GPP Evolved Packet Core (EPC) architecture is a Packet Data Network (PDN). A PDN is an Internet Protocol (IP) network. This is typically Internet, but it can also be a closed corporate network or an operator service network. A PDN has one or more names, each name represented in a string called Access Point Name (APN). A PDN gateway (PDN-GW or PGW) is a functional node that provides access to one or more PDNs. The interface between the PGW and the PDN is called SGi.
A PDN connection provides a User Equipment (UE) with an access channel to a PDN. It is a logical IP tunnel between the UE and PGW. Each PDN connection has a single IP address/prefix. A UE can setup multiple PDN connections, possibly to the same APN.
The access network between UE and PGW is either a Third Generation Partnership Program (3GPP) access or a non-3GPP access. In the former, the radio technology between UE and network is defined by 3GPP; e.g. Long Term Evolution (LTE). In the latter, the radio technology is not defined by 3GPP; e.g. Wireless Local Area Network (WLAN). A UE can setup one or more PDN connections over a 3GPP access or over a non-3GPP access or over both.
FIG. 1 shows an architecture setup where the UE is connected via LTE (E-UTRAN) to the network. User plane traffic is routed via the S5 interface. The PDN is denoted as “Operator's IP Services”. This figure and other architecture variants can be found in 3GPP Technical Specification (TS) 23.401.
FIG. 2 is an architecture setup where the UE is connected to the network via a non-3GPP access. User plane traffic is routed via the S2 interface. This figure and other architecture variants can be found in 3GPP TS 23.402.
Note that a UE can setup multiple PDN connections simultaneously, possibly via multiple accesses. E.g. it is possible that a UE has one PDN connection via LTE and simultaneously one PDN connection via WLAN.
The Internet Engineering Task Force (IETF) is currently working on mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The extensions to TCP, called multi-path TCP (MPTCP) are described in IETF Request for Comments (RFC) 6824. Architectural guidelines for multipath TCP development have been published in IETF RFC 6182. RFC 6182 defines a path as: A sequence of links between a sender and a receiver, defined in this context by a source and destination address pair.
Standard TCP/IP communication (without MPTCTP) is restricted to a single path per connection. However, in many cases, multiple paths exist between peers, e.g. in case one or both of the end-devices is multi-homed and/or has connectivity via more than one access technology. For example, in a 3GPP multi-access scenario a device (3GPP UE) may be connected via both a 3GPP access (such as GSM EDGE Radio Access Network (GERAN), UMTS Terrestrial Radio Access Network (UTRAN) and evolved UTRAN (E-UTRAN)) and WLAN access simultaneously. The simultaneous use of these multiple paths for a TCP/IP session improves resource usage within the network, and improves user experience through higher throughput and improved resilience to network failure. The use of MPTCP over multiple accesses allows the user traffic to be either routed only over one of the accesses or simultaneously over multiple accesses. It will also allow the traffic to be moved in a seamless fashion between accesses depending on coverage, radio link quality and other factors.
Because the same socket application programming interface (API) is used, MPTCP imposes no impact to the application layer. MPTCP can distribute load on available interfaces, can increase bandwidth, and allows for seamless handover between two accesses. MPTCP can run end-to-end between device and server. There can alternatively be an MPTCP proxy between device and server. With a proxy there is no need to upgrade servers with MPTCP support. Also, the proxy can do traffic steering. The latter is in particular interesting for an operator when the proxy is placed in the operator's network. The proxy may be placed in the PGW or just above the PGW on the SGi interface.
FIG. 3 is taken from 3GPP TS 23.203 and visualizes the 3GPP policy control and charging (PCC) architecture. All functional elements are defined and described in 3GPP TS 23.203. The Policy and Charging Rules Function (PCRF) is the central controller. The PCRF sends rules to a Policy and Charging Enforcement Function (PCEF), which does the actual enforcement of the rules. A PCRF may take a policy decision based on a trigger, e.g. from an Application Function (AF) or a Traffic Detection Function (TDF). There are also a Subscription Profile Repository (SPR), an Online Charging System (OCS), an Offline Charging System (OFCS) and a Bearer Binding and Event Reporting Function (BBERF).
A relevant interface is the Gx interface between PCEF and PCRF. A communication session over the Gx interface is called an IP-CAN session (IP Connectivity Access Network). 3GPP TS 23.203 defines an IP-CAN session as: The association between a UE and an IP network. The association is identified by one IPv4 and/or an IPv6 prefix together with UE identity information, if available, and a PDN represented by a PDN ID (e.g. an APN). In other words, each IP-CAN session corresponds to a PDN connection.
A PCC rule is a rule sent over an IP-CAN session from PCRF to PCEF. Such a rule consists, simplified, of the following elements: 1) a name; 2) the applicability, which is a description to which traffic this rule applies, i.e. basically a set of IP n-tuples with wildcards; 3) a policy defining what to do with the traffic this rule applies to; and 4) charging parameters.
The policy e.g. could be: Gating status, defining if traffic may pass (gate open) or not (gate close); The quality-of-service (QoS) class identifier (QCI), defining the QoS of the traffic; Uplink and downlink maximum bitrate (MBR); Uplink and downlink guaranteed bitrate (GBR); The Allocation and Retention Priority (ARP).
When PCC rules are sent to a PCEF, the PCEF may decide to setup or modify one or more bearers of the connection. A bearer uniquely identifies traffic that receives a common QoS treatment between a UE and a PDN GW. Each PDN connection has at least one bearer, the default bearer. On top of that a PDN connection may have one or more dedicated bearers.
Referring to FIG. 4, assuming we have an MPTCP proxy in the network, either co-located in the PGW or just above the PGW on SGi. One way to enforce policies would be to do the policy enforcement on the left side, between the proxy and the UE. In this approach the PCRF would see three IP addresses that are related to each other: two between the proxy and the UE, and an IP address with an Rx session for the aggregate. Note that the actual IP address value for the aggregate may be the value of the two, or it may be a new value. In the latter case the proxy is acting as a Network Address Translator (NAT).
The PCRF would need an interface towards the proxy such that it can understand how the connections are related. This new interfaces is denoted Yz in FIG. 4.
The PCRF can send access-specific rules via the two left side Gx interfaces. However, it is impossible for the PCEF to send rules that apply for the aggregate of traffic. For that to work, the PCRF will need to be able to control a PCEF to the right side of the proxy in FIG. 4. In the generic case, in order for the PCRF to have full flexibility, PCEFs on both the left and right side of the proxy are required.
Note that the MPTCP proxy may be acting as NAT, as explained above. Non-MPTCP traffic will not pass the proxy. However, such non-MPTCP traffic could still be NATed. That way, all of the UE's traffic on the right side of the proxy is aggregated in the right side connection.
The generic MPTCP PCC architecture impacts the PCRF in a number of ways:                The PCRF needs to understand the correlation between the three different connections. This implies a new Yz interface between proxy and PCEF.        The notion that each IP-CAN is independent and has one IP address does no longer hold.        
This causes not only a re-design of the PCRF. It also requires that the 3GPP standard for the PCRF is modified.